[アップデート] AWS Batch の Fargate タイプで OS ファミリと CPU アーキテクチャが指定出来るようになったので、Windows コンテナで実行してみた
いわさです。
AWS Batch を使うと大規模な並列ジョブをマネージドサービスとして実行することが可能です。
これまでは Linux x86 環境のみプラットフォームとしてサポートされており、Windows コンテナを使いたい場合などは AWS Batch は採用出来ませんでした。
先日の AWS Batch のアップデートで、プラットフォームに Linux ARM 64 と Windows が追加されました。
まず、これまでは Windows ワークロードを AWS Batch で利用することは出来ませんでしたが今後は利用出来るようになります。
また、Linux の場合は ARM 64 が選択出来るようになりました。
これによって ARM 64 に最適な処理であれば、従来よりもコストパフォーマンスが良くなる可能性があります。
本日は Windows コンテナのジョブ定義を作成して実行してみましたので手順などを紹介します。
なお、本日時点では AWS CLI/SDK 経由のみで設定が可能で、マネジメントコンソールからの Windows コンテナジョブ定義作成はサポートされていませんのでご注意ください。
Windows コンテナのジョブ定義を作成
今回のアップデートでは AWS CLI/SDK 経由のみですが、ジョブ定義を作成する際に Fargate タイプで OS ファミリと CPU アーキテクチャを指定することが出来るようになっています。
ジョブ実行前に Fargate 用の ECS タスク定義が作成されますが、その際に指定した OS ファミリと CPU アーキテクチャ内容が反映されるようになっています。
{ "jobDefinitionName": "hoge0717win", "type": "container", "containerProperties": { "image": "mcr.microsoft.com/windows/servercore:ltsc2019", "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole", "resourceRequirements": [ { "value": "1", "type": "VCPU" }, { "value": "4096", "type": "MEMORY" } ], "command": [ "systeminfo" ], "networkConfiguration": { "assignPublicIp": "ENABLED" }, "runtimePlatform": { "operatingSystemFamily": "WINDOWS_SERVER_2019_CORE", "cpuArchitecture": "X86_64" } }, "platformCapabilities": [ "FARGATE" ] }
上記はregister-job-definition
サブコマンドのパラメータです。
ハイライト部分のruntimePlatform
が今回の追加された部分です。
operatingSystemFamily
で OS ファミリを、cpuArchitecture
で CPU アーキテクチャを指定します。そのまんまですが。
operatingSystemFamily
で許容されているパラメータは従来と同じモードのLINUX
と、Windows の場合は次の 4 つが本日時点でサポートされています。
WINDOWS_SERVER_2019_CORE
WINDOWS_SERVER_2019_FULL
WINDOWS_SERVER_2022_CORE
WINDOWS_SERVER_2022_FULL
cpuArchitecture
では従来と同じモードのX86_64
に加えてARM64
が追加されています。
今回は Windows Server 2019 Core を指定してみました。
なお、Windows コンテナを使う場合は ARM64 を指定することは出来ません。
AWS Batch の実体は各コンピューティングサービスであり、今回の場合は Fargate になります。
制限事項などもそのまま Fargate Windows のものが適用されますので、以下に目を通しておきましょう。
例えば、vCPU は最低 1 からです。
料金も実行環境ベースでの算出なので Fargate Spot は利用出来ないですし、Windows コンテナの場合は料金は 1 秒あたりの計算となり最低 15 分からとなってます。
利用にあたっては制限事項や料金など Windows Fargate 固有の制限を把握しておく必要があります。
あとは作成したタスク定義を登録します。
% aws batch register-job-definition --cli-input-json file://def-windows1.json { "jobDefinitionName": "hoge0717win", "jobDefinitionArn": "arn:aws:batch:ap-northeast-1:123456789012:job-definition/hoge0717win:1", "revision": 1 }
マネジメントコンソール上のジョブ定義一覧画面からだと、runtimePlatform
の内容が確認出来ないので、正しく設定出来ているかわからないですが、新しくジョブ定義は作成されていますね。
ジョブ定義詳細画面を見てみると、登録した定義内容が JSON で確認することは出来ます。
ジョブ実行
作成した Windows コンテナのジョブ定義を実行してみましょう。
実行にあたってコンピューティング環境(Fargate)やジョブキューは準備済みとします。
実行後に CloudWatch Logs から出力を確認してみましょう。
実行したジョブではsysteminfo
コマンドを実行するものとなっています。
お、出力されていますね。OS Name も Microsoft Windows Server 2019 Datacenter と出力されています。
良さそうです。
ちなみに、AWS Batch から Fargate のタスク定義も作成されおり、こちらでは Windows Server 2019 Core のタスク定義が作成されたことが確認出来ます。
リビジョン作成は可能
マネジメントコンソールから今回の機能はまだ操作出来ないのですが、Windows ベースのジョブ定義からリビジョン作成操作を行うことは出来ました。
今回次のように実行メモリ値を変更して確認してみたのですが、runtimePlatform
は Windows が指定されていたので、リビジョン作成についてはマネジメントコンソールから問題なく実施出来るようです。
ベースのコマンド更新したい場合とかあると思うので、これはありがたい。
マネジメントコンソールからはやはり新規作成はできなかった
リビジョンが作成出来たので、もしかして Windows コンテナイメージが指定されていれば新規ジョブ定義作成でもマネジメントコンソール上で自動でプラットフォーム判定して良しなにやってくれるのでは?と思って一応試してみました。
作成されたジョブ定義の中身を見てみると、runtimePlatform
が設定されていないですね。
つまり x86 Linux ということです。
そのうちにマネジメントコンソールでも対応されそうな気もしますが、本日時点では AWS CLI/SDK からの新規登録が必須ということで覚えておいてください。
さいごに
本日は AWS Batch の Fargate タイプで OS ファミリと CPU アーキテクチャが指定出来るようになったので、Windows コンテナで実行してみました。
コスト削減などで ARM 64 の採用を検討することが多いと思いますが、今後は AWS Batch でも ARM 64 の検討しても良いかもしれないですね。
また、Windows コンテナのサポートについては、対抗の Azure Batch ではこれまでサポートされていたので、AWS Batch でもサポートされるようになったのは嬉しい人がいるかもしれないですね。